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Abstract. Alpaga is a solver for two-player parity games with imperfect infor- 
mation. Given the description of a game, it determines whether the first player 
can ensure to win and, if so, it constructs a winning strategy. The tool provides a 
symbolic implementation of a recent algorithm based on antichains. 



1 Introduction 

Alpaga is a tool for solving parity games with imperfect information. These are games 
played on a graph by two players; the first player has imperfect information about the 
current state of the play. We consider objectives over infinite paths specified by parity 
conditions that can express safety, reachability, liveness, fairness, and most properties 
commonly used in verification. Given the description of a game, the tool determines 
whether the first player has a winning strategy for the parity objective and, if this is the 
case, it constructs such a winning strategy. 

The Alpaga implementation is based on a recent technique using antichains for solv- 
ing games with imperfect information efficiently [2], and for representing the strategies 
compactly JT|. To the best of our knowledge, this is the first implementation of a tool 
for solving parity games with imperfect information. 

In this paper, we outline the antichain technique which is based on fixed-point com- 
putations using a compact representation of sets. Our algorithm essentially iterates a 
controllable predecessor operator that returns the states from which a player can force 
the play into a given target set in one round. For computing this operator, no polynomial 
algorithms is known. We propose a new symbolic implementation based on BDDs to 
avoid the naive enumerative procedure. 

Imperfect-information games arise in several important applications related to ver- 
ification and synthesis of reactive systems. The following are some key applications: 
(a) synthesis of controllers for plants with unobservable transitions; (b) distributed syn- 
thesis of processes with private variables not visible to other processes; (c) synthesis 
of robust controllers; (d) synthesis of automata specifications where only observations 
of automata are visible, and (e) the decision and simulation problem of quantitative 
specification languages; (f) model-checking secrecy and information flow. We believe 
that the tool Alpaga will make imperfect information games a useful framework for 



designers in the above applications. In the appendix, we present a concrete example 
of distributed-system synthesis. Along the lines of [3], we consider the design of a 
mutual-exclusion protocol for two processes. The tool Alpaga is able to synthesize a 
winning strategy for a requirement of mutual exclusion and starvation freedom which 
corresponds to Peterson's protocol. 

2 Games and Algorithms 

Let E be a finite alphabet of actions and let f be a finite alphabet of observations. 
A game structure with imperfect information over E and _T is a tuple G = (L, Iq, A, 7), 
where 

- L is a finite set of locations (or states), 

- Iq £ L is the initial location, 

- A C L x E x L is a set of labelled transitions such that for all I £ L and all a £ E, 
there exists £' £ £ such that (£, a, £') € Z\, i.e., the transition relation is total, 

- 7 : r — > 2 L \ is an observability function that maps each observation to a set 
of locations such that the set {7(0) | o £ r} partitions L. For each t £ L, let 
obs(£) = o be the unique observation such that I £ 7(0). 

The game on G is played in rounds. Initially, a token is placed in location Iq. In 
every round, Player 1 first chooses an action a £ E, and then Player 2 moves the token 
to an a-successor £' of the current location I, i.e., such that (£, a, £') £ A. Player 1 does 
not see the current location I of the token, but only the observation obs(£) associated to 
it. A strategy for Player 1 in G is a function a : _T + — > E. The set of possible outcomes 
of a in G is the set Outcome(G, a) of sequences 7r = iiio, . . . such that l\ = ?o and 
(£i, a(obs(^i . . . £i)),£i + i) £ A for all i > 1. A visible parity condition on G is defined 
by a function p : f — > N that maps each observation to a non-negative integer priority. 
We say that a strategy a for Player 1 is winning if for all tt £ Outcome(G, a), the least 
priority that appears infinitely often in tt is even. 

To decide whether Player 1 is winning in a game G, the basic approach consists 
in tracing the knowledge of Player 1, represented a set of locations called a cell. The 
initial knowledge is the cell sq = {lo}. After each round, the knowledge s of Player 1 
is updated according to the action a she played and the observation o she receives, to 
s' = postjs) 07(0) where post Q (s) = {(.' £ L \ 3£ £ s : (£,a,£ r ) e A}. 

Antichain algorithm. The antichain algorithm is based on the controllable predecessor 
operator CPre : 2 s — > 2 s which, given a set of cells q, computes the set of cells q' from 
which Player 1 can force the game into a cell of q in one round: 

CPre(g) = {s C L \ 3a £ E ■ Vo £ r : post a (s) n 7(0) £ q}. (1) 

The key of the algorithm relies on the fact that CPre(-) preserves downward-closedness. 
A set q of cells is downward-closed if, for all s £ q, every subset s' C s is also in q. 
Downward-closed sets q can be represented succinctly by their maximal elements r = 
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\q] = {s G q | Vs' E g : s *t- s '}> which form an antichain. With this representation, 
the controllable predecessor operator is defined by 

CPre(r) = \{s C L | 3a G 17 ■ Vo G T • 3s' G r : post Q (s) n 7(0) C s'}] . (2) 

Strategy construction. The implementation of the strategy construction is based on [T). 
The algorithm of 0] employs antichains to compute winning strategies for imperfect- 
information parity games in an efficient and compact way: the procedure is similar to the 
classical algorithm of McNaughton |4| and Zielonka |6| for perfect-information parity 
games, but, to preserve downwards closure, it avoids the complementation operation 
of the classical algorithms by recurring into subgames with an objective obtained as a 
boolean combination of reachability, safety, and reduced parity objectives. 

Strategy simplification. A strategy in a game with imperfect information can be repre- 
sented by a set 77 = {(si, ranki, ai), . . . , (s n , rank„, a„)} of triples (si, rank^, a,) G 
2 L x N x U where s$ is a cell, and <ij is an action. Such a triple assigns action <ij to every 
cell s C 5^; since a cell s may be contained in many Si, we take the triple with minimal 
value of rank^ Formally, given the current knowledge s of Player 1, let (sj, rank;, ai) 
be a triple with minimal rank in 77 such that s C s, (such a triple exists if s is a winning 
cell); the strategy represented by 77 plays the action m in s. 

Our implementation applies the following rules to simplify the strategies and obtain 
a compact representation of winning strategies in parity games with imperfect informa- 
tion. 

(Rule 1) In a strategy 77, retain only elements that are maximal with respect to the 
following order: (s, rank, a) >; (s 1 , rank', a') if rank < rank' and s' C s. Intuitively, 
the rule specifies that we can delete (s' , rank', a') whenever all cells contained in s' are 
also contained in s; since rank < rank', the strategy can always choose (s, rank, a) and 
play a. 

(Rule 2) In a strategy 77, delete all triples (sj, rank^, ai) such that there exists 
(sj, rankj, aj) G il (i ^ j) with = aj, s, C Sj (and hence rank; < rank, by Rule 1), 
such that for all (sfc, rankfc, afc) G 77, if rank,; < rankfc < rankj and s, D Sfc 7^ 0, then 
a,; = afc. Intuitively, the rule specifies that we can delete (sj, rank;, aj) whenever all 
cells contained in Sj are also contained in Sj, and the action aj is the same as the action 
Oj. Moreover, if a cell s C Sj is also contained in S)t with rank^ < rankfc < rankj, then 
the action played by the strategy is also ak = ai = aj. 

3 Implementation 

Computing CPre(-) is likely to require time exponential in the number of observations 
(a natural decision problem involving CPre(-) is NP-hard [1]). Therefore, it is natural 
to let the BDD machinery evaluate the universal quantification over observations in (ffj. 
We present a BDD-based algorithm to compute CPre(-). 

Let L = {£1, ...,£„} be the state space of the game G. A cell s C L can be 
represented by a valuation v of the boolean variables x = xi, ■ ■ . , x n such that li G s 
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iff v(xi) = true, for all 1 < i < n. A BDD over xi, . . . , x n is called a linear encoding, 
it encodes a set of cells. A cell s C L can also be represented by a BDD over boolean 
variables y = yi, ■ ■ ■ ,y m with m = |~log 2 n] . This is called a logarithmic encoding, it 
encodes a single cell. 

We represent the transition relation of G by the n • \S\ BDDs T a (£i) (a E S, 
1 < i < n) with logarithmic encoding over y. So, T a (£i) represents the set {£j \ 
(£i,a, £j) E A}. The observations r = {oi, . . . , o p } are encoded by |~log 2 p] boolean 
variables b ,bi, . . . in the BDD B r defined by 

Br^ A ^=b']2-Q+i(y), 

0<j<p-l 

where [j] 2 is the binary encoding of j and Ci , . . . , C p are BDDs that represent the sets 
7(01), . . . , 7(o p ) in logarithmic encoding. 

Given the antichain q = {s\, . . . , s t }, let Sk (1 < k < t) be the BDDs that encode 
the set Sk in logarithmic encoding over y. For each a G S, we compute the BDD CP a 
in linear encoding over x as follows: 

CP a =Vfe- \/ f\ [Vy ■ (T a (£i) A B r ) ->5 fc ]. 

l<fc<t l<i<n 

Then, we define CP = V aeS CP a (q), and we extract the maximal elements in CP(x) 
as follows, with w a BDD that encodes the relation of (strict) set inclusion C: 

n n 

uj{x, x') = ( f\xi ->■ x'^j A ( \/ Xi ^ x'^j , 
i=i i=i 

CP min (x) = CP(x) A -arf ■ w(x, x') A CP(x'). 

Finally, we construct the antichain CPre(g) as the following set of BDDs in logarithmic 
encoding: CPre(g) = {s \ 3v E CP min : s = {£ t \ v( Xi ) = true}}. 

Features of the tool. The input of the tool is a file describing the transitions and ob- 
servations of the game graph. The output is the set of maximal winning cells, and a 
winning strategy in compact representation. We have also implemented a simulator to 
let the user play against the strategy computed by the tool. The user has to provide an 
observation in each round (or may let the tool choose one randomly). The web page of 
the tool is http : / /www . ant i chains . be/alpaga. We provide the source code, 
the executable, an online demo, and several examples. Details of the tool features and 
usage are given in the appendix. 
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Details of Tool Features 



4 Practical implementation 

In this section we describe the implementation details of the tool Alpaga. 

4.1 Programming Language 

Alpaga is written in Python, except for the BDD package which is written in C. We 
use the CUDD BDD library 0, with its PYCUDD Python binding. There is some 
performance overhead in using Python, but we chose it for enhanced readability and to 
make the code easy to change. We believe this is important in the context of academic 
research, as we expect other researchers to experiment with the tool, tweak the existing 
algorithms and add their own. 

Alpaga is available for download at http : / /www . antichains . be/alpaga 
for Linux stations. For convenience, the tool can also be tested through a web interface 
(see Fig.Q]for a glimpse to this interface). 

4.2 Code architecture 

The code consists of four main classes: 

1. Game is the main class of Alpaga. It encompasses all necessary information de- 
scribing a game: BDDs for initial sets, target sets, observations, transition relations. 
The class offers two implementations of the controllable predecessors operator: 
(a) the"enumerative" CPre implementation which closely follows the definition of 
the CPre operator (enumerating labels, states and sets of the antichains, comput- 
ing desired antichain intersections and unions as it progresses) and (b) the CPre 
implementation following the BDD technique explained in Section[3] 
Furthermore, the class offers a large set of utility functions to compute, for exam- 
ple, the successors of a set of states, its controllable predecessors, and to manipulate 
antichains of sets of states of the game. At a higher level, the class offers methods 
to compute strategies for specific kinds of objectives (ReachAndSafe: solving con- 
junction of reachability and safety objectives, and ReachOrSafe: solving disjunc- 
tion of reachability and safety objectives). Finally it includes the implementation 
of the algorithm of [ 1 1 using all previous functions. 

2. P a r s e r produces an instance of the class Game from an input file. The parser also 
offers a good amount of consistency checking (it checks, for example, that every 
state belongs to one and only one observation). 

3. St rategy is the class with data structure for strategy representation. The descrip- 
tion of a strategy is based on the notion of rank (similar to rank of /i-calculus 
formulas), and a strategy maps a cell with a rank to a label and a cell with smaller 
rank. 

4. StrategyPlayer is the class implementing the interactive mode of Alpaga. It 
takes as argument a game and a strategy and allows the user of Alpaga to replay the 
strategy interactively (see below). 



6 




Test A^aga Onine 



Enter your input in the text area here under or choose a file to toad 

□ E numeral ue C P R E Show compulsion limes 

□ Turn oil lolalizalion oi I rare- h ion lelalbn □ v erbose mode 



ALPHABET : a 
STATES : 1, 2, 3 
I II IT : X 

SAFE : 1,2,3 
TARGET : 2 
TRAHS : 
3U 1 , a 
1,2, a 

2. 3, a 

3, 3,a 
OBS : 
1:1 
2:1 
3:8 



| Submit j 

Some- Games You Can Use to Test the- Tool 



4.3 User Manual 

In this section we describe the syntax of the input file, how to read the output, the 
various options of the tool, and finally we describe the interactive use of the tool. 

Input. The syntax of the tool is straightforward and follows the formal description of 
imperfect information parity games as described in Section [2] Our algorithm solves 
games with objectives that are of the following form: parity objectives in conjunction 
with a safety objective, along with the disjunction with a reachability objective. The 
parity objective can be obtained as a special case when the safe set is the full set of 
states, and the target set for reachability objective is empty. In the description below, 
we have the safe and target set for the safety and reachability objectives, respectively. 
We present the following example: 




Fig. 1. Alpaga web interface. 
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ALPHABET : a 
STATES : 1, 2,3 
INIT : 1 
SAFE : 1,2,3 
TARGET : 2 
TRANS : 

1, 1 , a 
1,2, a 

2, 3, a 

3 , 3 , a 
OBS : 
1 : 1 
2 : 1 
3:0 

The input file describing a parity game with imperfect information is constructed as 
follows: 

- the sets of labels, states, initial states, safe states, and target states are all specified 
on a single line introduced by the corresponding keyword ALPHABET, STATES, 
INIT, SAFE or TARGET. The name of the states and labels can be any string ac- 
cepted by Python that does not include a blank space or the # character (which is 
used for comments). However, the keyword SINK is reserved (see below). 

- the transition relation is defined on a sequence of lines introduced by the keyword 
TRANS on a single line. After the TRANS keyword, each line specifies on a single 
line a transition, by giving the initial state, the destination state and the label of the 
transition, all separated by commas. 

- Finally, the observations and corresponding priorities are specified in a similar fash- 
ion. They are introduced by the keyword OBS on a single line. Then follows the 
specification of the observations. Each observation is specified on a single line as a 
set of comma-separated states, followed by its priority (a positive integer number) 
which must be preceded by a colon. 

- Blank lines are allowed anywhere as empty comments. Nonempty comments start 
with the character # and extend to the end of the line. 

Output. The tool output for our example is in Fig. [2] The winning strategy computed 
by the tool is represented by a list of triples (a, rank, s) G E x N x 2 L where a is an 
action, and s is a cell. The strategy is represented in the compact form after applying 
Rule 1 and Rule 2 for simplification of strategies. The strategy representation can be 
used to find the action to play, given the current knowledge s' of Player 1 as follows: 
play the action a such that (a, rank, s) is a triple in the list with minimal rank such that 
s' C s (such a triple must exist if s' is a winning cell). 

Tool options. We now describe the various options with which the tool can be used. 

alpaga.py [options] file 
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The possible options are the following: 

- -h Shows an help message and exits. 

- -i After computing a strategy, launches the interactive strategy player which allows 
to see how the strategy computed by the tools executes in the game. In this mode, 
the tool shows which move is played by the strategy, given the current knowledge 
(i.e., a set of states in which the player can be sure that the game is - the initial 
knowledge is the set of initial states). Then the tool allows to choose the next ob- 
servations among the observations that are compatible with the current knowledge. 

- -e Uses the enumerative CPre in all computations. There are two different imple- 
mentations for the controllable predecessor operator (CPre), one temporarily using 
a linear encoding of the resulting antichain for the time of the computation, and an 
enumerative algorithm following closely the definition of the CPre operator. 

- -n Turns off the totalization of the transition relation. By default, Alpaga completes 
the transition relation so that it becomes total, which means that a transition of 
every label exists from each state. Therefore, Alpaga first adds a state named SINK 
with priority 1 (corresponding to a new observation), from which every label loops 
back to SINK, and then adds a transition 

s, SINK, lab 

for each pair (s, lab) such that there does not exist a transition from state s on label 
lab. Note that the name SINK is reserved. 

- -r Turns on the display of stack traces in case of error. 

- -s Turns off the simplification of the strategies before display. 

- -t Displays computation times, which includes time for parsing the file (and con- 
structing the initial BDDs), time for initializing the linear encoding, for computing 
a strategy, and for simplifying that strategy. 

- -v Turns on the display of warnings, which mainly list the transitions added by the 
totalization procedure. 

Interactive mode. After computing a strategy for a parity game, the tool can switch to 
interactive mode, where the user can "replay" the strategy, to check that the modeliza- 
tion was correct. The user of Alpaga plays the role of Player 2, choosing the observation 
among the compatible observations available, and getting the resulting knowledge of 
player 1 and which move she will play. 

Practically, in interactive mode, type help for the list of commands: the standard 
way for playing a strategy is the following: launch alpaga with option -i, type go at the 
interactive prompt, type the number of an observation, type enter twice, repeat. Fig. [3] 
shows an interactive Alpaga session. 

5 Example: mutual-exclusion protocol 

We demonstrate the use of games with imperfect information to synthesize reactive 
programs in distributed systems. We consider the design of a mutual-exclusion protocol 
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File Edit View Terminal Tabs Help 

madewulf@madewulf - desktop :~/workspace/alpaga$ alpaga. py -v -t exampl.es/parityGaiite2.gii 



Parsing Time 
Initialization Time 
Solving Time 
Simplifying Time 



B. 00803303718567 S 
0.000717878341675 s 
0.0134789943695 5 
9.41753387451e-05 

S. S22324Q852356 5 



Total Time 
Winning Cells : 
{ 

{ 3 , 2 } 

} 

Strategy : 

(a, 1) : { 3 , 2 } 

The initial set is not winning 

madewulftamadewulf - desktop :~/wo rkspace/alpagas 



Fig. 2. Output of Alpaga. 



BIB 



File Edit View Terminal Tabs Help 
The initial set is winning 
Alpaga interactive mode 



S 



Available commands 
»suinma ry 
Winning Cells : 
{ 

{ 1 , 3 , 2 , 

} 

Strategy : 

(a, 1) : { 1 , 3 

Current Knowledge : 

{ 1 } 

»go 



go , exit, reinit, help, summary 



4 > 



4 > 



The Strategy plays : a 
Current Knowledge : 
{3,2} 

The possible next observations are : 

1 : { 2 } 

2 : { 3 } 

Pick a number (keep blank for random) : 1 
Current Knowledge : 
{ 2 } 

» 



The Strategy plays : a 
Current Knowledge : 
{ 4 } 

The possible next observations are : 
1 : { 4 } 

Pick a number (keep blank for random) : | 



Fig. 3. Interactive strategy player of Alpaga. 



10 



do { 

unbounded_wait ; 
flag [ 1 ] : =true; 
turn : =2 ; 



do { 

unbounded_wait ; 
flag [ 2 ] : =true; 
turn : =1 ; 



while ( flag [ 1 ] ) nop; 
while ( flag [ 2 ] ) nop; 
while (turn=l ) nop; 
while (turn=2 ) nop; 



(CI) 
(C2) 
(C3) 
(C4) 
(C5) 
(C6) 
(C7) 
(C8) 



while ( flag [ 1 ] & turn=l) nop; 



while ( flag [ 1 ] & turn=2) nop; 

while ( flag [ 1 ] & turn=l) nop; 

while ( flag [ 2 ] & turn=l) nop; 

while ( flag [ 2 ] & turn=2) nop; 



fin_wait; // Critical section 
flag [ 1 ] : =f alse; 
} while (true) 



fin_wait; // Critical section 
flag [ 2 ] : =f alse; 
} while (true) 



Fig. 4. Mutual-exclusion protocol synthesis. 



for two processes, following the lines of [3 1. We assume that one process (on the right 
in Fig.|4]l is completely specified. The second process (on the left in Fig. |4j has freedom 
of choice in line 4. It can use one of 8 possible conditions C1-C8 to guard the entry 
to its critical section in line 5. The boolean variables f lag[l] and f lag[2] are used to 
place a request to enter the critical section. They are both visible to each process. The 
variable turn is visible and can be written by the two processes. Thus, all variables are 
visible to the left process, except the program counter of the right process. 

There is also some nondeterminism in the length of the delays in lines 1 and 5 of 
the two processes. The processes are free to request or not the critical section and thus 
may wait for an arbitrary amount of time in line 1 (as indicated by unboundecLwait), 
but they have to leave the critical section within a finite amount of time (as indicated by 
f in_wait). In the game model, the length of the delay is chosen by the adversary. 

Finally, each computation step is assigned to one of the two processes by a sched- 
uler. We require that the scheduler is fair, i.e. it assigns computation steps to both pro- 
cesses infinitely often. In our game model, we encode all fair schedulers by allowing 
each process to execute an arbitrary finite number of steps, before releasing the turn 
to the other process. Again, the actual number of computation steps assigned to each 
process is chosen by the adversary. 

The mutual exclusion requirement (that the processes are never simultaneously in 
their critical section) and the starvation freedom requirement (that whenever the left 
process requests to enter the critical section, then it will eventually enter it) can be 
encoded using three priorities. 

When solving this game with our tool, we find that Player 1 is winning, and that 
choosing C% is a winning strategy. 
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